Methods, systems, and apparatuses for using a vehicle identification profile to determine whether a vehicle has been stolen

ABSTRACT

Provided are methods, systems, and apparatuses for determining driver behavior based on vehicle operating parameters, adjusting insurance premiums accordingly, and preventing fraudulent manipulation of the methods, systems, and apparatuses.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Application No.60/910,870 filed Apr. 10, 2007, herein incorporated by reference in itsentirety.

SUMMARY

In one aspect, provided are methods for determining driver behavior,comprising receiving vehicle performance data, determining a driversafety metric based on the vehicle performance data, and transmittingthe safety metric to a remote host.

In another aspect, provided are methods for insurance premiumadjustment, comprising receiving vehicle performance data, analyzing thevehicle performance data to determine one or more behaviors, andadjusting an insurance premium based on the one or more behaviors.

In yet another aspect, provided are methods for fraud detection,comprising retrieving a vehicle identification parameter through avehicle bus, comparing the retrieved vehicle identification parameterwith a stored vehicle identification profile, and performing a fraudaction based on the comparison.

Additional advantages will be set forth in part in the description whichfollows or may be learned by practice. The advantages will be realizedand attained by means of the elements and combinations particularlypointed out in the appended claims. It is to be understood that both theforegoing general description and the following detailed description areexemplary and explanatory only and are not restrictive, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate embodiments and together with thedescription, serve to explain the principles of the methods and systems:

FIG. 1 is a schematic of an exemplary apparatus;

FIG. 2 is an external view of an embodiment of an exemplary apparatus;

FIG. 3 is an exemplary system;

FIG. 4 is an exemplary user interface;

FIG. 5 is an exemplary operating environment for disclosed methods;

FIG. 6 is a flow diagram illustrating an exemplary method fordetermining driving behavior;

FIG. 7 is a flow diagram illustrating an exemplary method for insurancepremium adjustment;

FIG. 8 is a flow diagram illustrating an exemplary method for frauddetection;

FIG. 9 is an exemplary apparatus; and

FIG. 10 is an exemplary system.

DETAILED DESCRIPTION

Before the present methods, systems, and apparatuses are disclosed anddescribed, it is to be understood that the methods, systems, andapparatuses are not limited to specific synthetic methods, specificcomponents, or to particular compositions, as such may, of course, vary.It is also to be understood that the terminology used herein is for thepurpose of describing particular embodiments only and is not intended tobe limiting.

As used in the specification and the appended claims, the singular forms“a,” “an” and “the” include plural referents unless the context clearlydictates otherwise. Ranges may be expressed herein as from “about” oneparticular value, and/or to “about” another particular value. When sucha range is expressed, another embodiment includes from the oneparticular value and/or to the other particular value. Similarly, whenvalues are expressed as approximations, by use of the antecedent“about,” it will be understood that the particular value forms anotherembodiment. It will be further understood that the endpoints of each ofthe ranges are significant both in relation to the other endpoint, andindependently of the other endpoint.

“Optional” or “optionally” means that the subsequently described eventor circumstance may or may not occur, and that the description includesinstances where said event or circumstance occurs and instances where itdoes not.

The present methods, systems, and apparatuses may be understood morereadily by reference to the following detailed description of preferredembodiments and the Examples included therein and to the Figures andtheir previous and following description.

Provided are methods, systems, and apparatuses that can utilize GPScapabilities and two-way in-vehicle data communications between an incar device and a telematics operations center. The methods, systems, andapparatuses enable a company, such as an insurance company, to gatherdata and develop relevant analytics. The methods, systems, andapparatuses can allow a company to provide offerings such as vehiclediagnostics and vehicle/driver tracking. These offerings can be at thediscretion of a customer.

The methods, systems, and apparatuses can comprise an embedded GPS andcellular transceiver to support real-time, remote driver and vehicleperformance metrics. GPS data can enhance the value and functionality ofaccurate location-based information. A dedicated data channel in thehardware can provide vehicle and driver information at a much morereliable and faster rate.

Benefits of the provided methods, systems, and apparatuses include, butare not limited to, a self-service interface allowing proactive vehiclemanagement and personalization, real-time vehicle data access on driverbehavior and diagnostics, enhanced customer relationship management,hence increasing customer loyalty.

In one aspect, provided is an apparatus comprising a telematics unit.The apparatus can be installed in a vehicle. Such vehicles include, butare not limited to, personal and commercial automobiles, motorcycles,transport vehicles, watercraft, aircraft, and the like. For example, anentire fleet of a vehicle manufacturer's vehicles can be equipped withthe apparatus. The apparatus 101 is also referred to herein as the VTU101. The apparatus can perform any of the methods disclosed herein inpart and/or in their entireties.

All components of the telematics unit can be contained within a singlebox and controlled with a single core processing subsystem or can becomprised of components distributed throughout a vehicle. Each of thecomponents of the apparatus can be separate subsystems of the vehicle,for example, a communications component such as a SDARS, or othersatellite receiver, can be coupled with an entertainment system of thevehicle.

An exemplary apparatus 101 is illustrated in FIG. 1. This exemplaryapparatus is only an example of an apparatus and is not intended tosuggest any limitation as to the scope of use or functionality ofoperating architecture. Neither should the apparatus be necessarilyinterpreted as having any dependency or requirement relating to any oneor combination of components illustrated in the exemplary apparatus. Theapparatus 101 can comprise one or more communications components.Apparatus 101 illustrates communications components (modules) PCS/CellModem 102 and SDARS receiver 103. These components can be referred to asvehicle mounted transceivers when located in a vehicle. PCS/Cell Modem102 can operate on any frequency available in the country of operation,including, but not limited to, the 850/1900 MHz cellular and PCSfrequency allocations. The type of communications can include, but isnot limited to GPRS, EDGE, UMTS, 1xRTT or EV-DO. The PCS/Cell Modem 102can be a Wi-Fi or mobile WIMAX implementation that can support operationon both licensed and unlicensed wireless frequencies. The apparatus 101can comprise an SDARS receiver 103 or other satellite receiver. SDARSreceiver 103 can utilize high powered satellites operating at, forexample, 2.35 GHz to broadcast digital content to automobiles and someterrestrial receivers, generally demodulated for audio content, but cancontain digital data streams.

PCS/Cell Modem 102 and SDARS receiver 103 can be used to update anonboard database 112 contained within the apparatus 101. Updating can berequested by the apparatus 101, or updating can occur automatically. Forexample, database updates can be performed using FM subcarrier, cellulardata download, other satellite technologies, Wi-Fi and the like. SDARSdata downloads can provide the most flexibility and lowest cost bypulling digital data from an existing receiver that exists forentertainment purposes. An SDARS data stream is not a channelizedimplementation (like AM or FM radio) but a broadband implementation thatprovides a single data stream that is separated into useful andapplicable components.

GPS receiver 104 can receive position information from a constellationof satellites operated by the U.S. Department of Defense. Alternately,the GPS receiver 104 can be a GLONASS receiver operated by the RussianFederation Ministry of Defense, or any other positioning device capableof providing accurate location information (for example, LORAN, inertialnavigation, and the like). GPS receiver 104 can contain additionallogic, either software, hardware or both to receive the Wide AreaAugmentation System (WAAS) signals, operated by the Federal AviationAdministration, to correct dithering errors and provide the mostaccurate location possible. Overall accuracy of the positioningequipment subsystem containing WAAS is generally in the two meter range.Optionally, the apparatus 101 can comprise a MEMS gyro 105 for measuringangular rates and wheel tick inputs for determining the exact positionbased on dead-reckoning techniques. This functionality is useful fordetermining accurate locations in metropolitan urban canyons, heavilytree-lined streets and tunnels.

In an aspect, the GPS receiver 104 can activate on ignition or start ofmotion. The GPS receiver 104 can go into idle on ignition off or afterten minutes without motion. Time to first fix can be <45 s 90% of thetime. For example, this can be achieved either through chipset selectionor periodic wake-up.

One or more processors 106 can control the various components of theapparatus 101. Processor 106 can be coupled to removable/non-removable,volatile/non-volatile computer storage media. By way of example, FIG. 1illustrates memory 107, coupled to the processor 106, which can providenon-volatile storage of computer code, computer readable instructions,data structures, program modules, and other data for the computer 101.For example and not meant to be limiting, memory 107 can be a hard disk,a removable magnetic disk, a removable optical disk, magnetic cassettesor other magnetic storage devices, flash memory cards, CD-ROM, digitalversatile disks (DVD) or other optical storage, random access memories(RAM), read only memories (ROM), electrically erasable programmableread-only memory (EEPROM), and the like. Data obtained and/or determinedby processor 106 can be displayed to a vehicle occupant and/ortransmitted to a remote processing center. This transmission can occurover a wired or a wireless network. For example, the transmission canutilize PCS/Cell Modem 102 to transmit the data. The data can be routedthrough the Internet where it can be accessed, displayed andmanipulated.

The processing of the disclosed systems and methods can be performed bysoftware components. The disclosed system and method can be described inthe general context of computer-executable instructions, such as programmodules, being executed by one or more computers or other devices.Generally, program modules comprise computer code, routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. The disclosed method canalso be practiced in grid-based and distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules can be located in both local and remotecomputer storage media including memory storage devices.

The methods and systems can employ Artificial Intelligence techniquessuch as machine learning and iterative learning Examples of suchtechniques include, but are not limited to, expert systems, case basedreasoning, Bayesian networks, behavior based AI, neural networks, fuzzysystems, evolutionary computation (e.g. genetic algorithms), swarmintelligence (e.g. ant algorithms), and hybrid intelligent systems (e.g.Expert inference rules generated through a neural network or productionrules from statistical learning).

Any number of program modules can be stored on the memory 107, includingby way of example, an operating system 113 and reporting software 114.Each of the operating system 113 and reporting software 114 (or somecombination thereof) can comprise elements of the programming and thereporting software 114. Data can also be stored on the memory 107 indatabase 112. Database 112 can be any of one or more databases known inthe art. Examples of such databases comprise, DB2®, Microsoft® Access,Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, and the like. Thedatabase 112 can be centralized or distributed across multiple systems.

In some aspects, data can be stored and transmitted in loss-lesscompressed form and the data can be tamper-proof. Non-limiting examplesof data that can be collected are as follows. After a connection isestablished the protocol being used can be stored. A timestamp can berecorded on ignition for one or more trips. Speed every second duringthe trip. Crash events can be stored (for example, as approximated viaOBD II speed). By way of example, GPS related data that can be recordedduring one or more trips can comprise one or more of, time, latitude,longitude, altitude, speed, heading, horizontal dilution of precision(HDOP), number of satellites locked, and the like. In one aspect,recorded data can be transmitted from the apparatus to a back-office forintegrity verification and then via, for example, a cellular network.Once validated, data can be pushed to a company via establishedweb-services & protocols.

By way of example, the operating system 113 can be a Linux (Unix-like)operating system. One feature of Linux is that it includes a set of “C”programming language functions referred to as “NDBM”. NDBM is an API formaintaining key/content pairs in a database which allows for quickaccess to relatively static information. NDBM functions use a simplehashing function to allow a programmer to store keys and data in datatables and rapidly retrieve them based upon the assigned key. A majorconsideration for an NDBM database is that it only stores simple dataelements (bytes) and requires unique keys to address each entry in thedatabase. NDBM functions provide a solution that is among the fastestand most scalable for small processors.

It is recognized that such programs and components reside at varioustimes in different storage components of the apparatus 101, and areexecuted by the processor 106 of the apparatus 101. An implementation ofreporting software 114 can be stored on or transmitted across some formof computer readable media. Computer readable media can be any availablemedia that can be accessed by a computer. By way of example and notmeant to be limiting, computer readable media can comprise “computerstorage media” and “communications media.” “Computer storage media”comprise volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules, orother data. Exemplary computer storage media comprises, but is notlimited to, RAM, ROM, EEPROM, flash memory or other memory technology,CD-ROM, digital versatile disks (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store thedesired information and which can be accessed by a computer.

FIG. 1 illustrates system memory 108, coupled to the processor 106,which can comprise computer readable media in the form of volatilememory, such as random access memory (RAM, SDRAM, and the like), and/ornon-volatile memory, such as read only memory (ROM). The system memory108 typically contains data and/or program modules such as operatingsystem 113 and reporting software 114 that are immediately accessible toand/or are presently operated on by the processor 106. The operatingsystem 113 can comprise a specialized task dispatcher, slicing availablebandwidth among the necessary tasks at hand, including communicationsmanagement, position determination and management, entertainment radiomanagement, SDARS data demodulation and assessment, power control, andvehicle communications.

The processor 106 can control additional components within the apparatus101 to allow for ease of integration into vehicle systems. The processor106 can control power to the components within the apparatus 101, forexample, shutting off GPS receiver 104 and SDARS receiver 103 when thevehicle is inactive, and alternately shutting off the PCS/Cell Modem 102to conserve the vehicle battery when the vehicle is stationary for longperiods of inactivity. The processor 106 can also control an audio/videoentertainment subsystem 109 and comprise a stereo codec and multiplexer110 for providing entertainment audio and video to the vehicleoccupants, for providing wireless communications audio (PCS/Cell phoneaudio), speech recognition from the driver compartment for manipulatingthe SDARS receiver 103 and PCS/Cell Modem 102 phone dialing, and text tospeech and pre-recorded audio for vehicle status annunciation.

The apparatus 101 can interface and monitor various vehicle systems andsensors to determine vehicle conditions. Apparatus 101 can interfacewith a vehicle through a vehicle interface 111. The vehicle interface111 can include, but is not limited to, OBD (On Board Diagnostics) port,OBD-II port, CAN (Controller Area Network) port, and the like. A cablecan be used to connect the vehicle interface 111 to a vehicle. Any typeof cable capable of connecting to a vehicle diagnostics port can beused. In one aspect, an OBD II connector cable can be used that followsthe J1962 trapezoidal connector specification, the J1939 or J1708 roundconnector specifications, and the like. A communication protocol suchas, J1850 PWM, J1850 VPW, ISO9141-2, ISO14230-4, and the like can beused to collect data through the vehicle interface 111. The vehicleinterface 111, allows the apparatus 101 to receive data indicative ofvehicle performance, such as vehicle trouble codes, operatingtemperatures, operating pressures, speed, fuel air mixtures, oilquality, oil and coolant temperatures, wiper and light usage, mileage,break pad conditions, and any data obtained from any discrete sensorthat contributes to the operation of the vehicle engine and drive-traincomputer. Additionally CAN interfacing can eliminate individualdedicated inputs to determine brake usage, backup status, and it canallow reading of onboard sensors in certain vehicle stability controlmodules providing gyro outputs, steering wheel position, accelerometerforces and the like for determining driving characteristics. Theapparatus 101 can interface directly with a vehicle subsystem or asensor, such as an accelerometer, gyroscope, airbag deployment computer,and the like. Data obtained from, and processed data derived from, thevarious vehicle systems and sensors can be transmitted to a centralmonitoring station via the PCS/Cell Modem 102.

Communication with a vehicle driver can be through an infotainment(radio) head (not shown) or other display device (not shown). More thanone display device can be used. Examples of display devices include, butare not limited to, a monitor, an LCD (Liquid Crystal Display), aprojector, and the like. Audio/video entertainment subsystem 109 cancomprise a radio receiver, FM, AM, Satellite, Digital and the like.Audio/video entertainment subsystem 109 can comprise one or more mediaplayers. An example of a media player includes, but is not limited to,audio cassettes, compact discs, DVD's, Blu-ray, HD-DVDs, Mini-Discs,flash memory, portable audio players, hard disks, game systems, and thelike. Audio/video entertainment subsystem 109 can comprise a userinterface for controlling various functions. The user interface cancomprise buttons, dials, and/or switches. In certain embodiments, theuser interface can comprise a display screen. The display screen can bea touch screen. The display screen can be used to provide informationabout the particular entertainment being delivered to an occupant,including, but not limited to Radio Data System (RDS) information, ID3tag information, video, and various control functionality (such as next,previous, pause, etc. . . . ), websites, and the like. Audio/videoentertainment subsystem 109 can utilize wired or wireless techniques tocommunicate to various consumer electronics including, but not limitedto, cellular phones, laptops, PDAs, portable audio players (such as aniPod), and the like. Audio/video entertainment subsystem 109 can becontrolled remotely through, for example, a wireless remote control,voice commands, and the like.

The methods, systems, and apparatuses provided can utilize a powermanagement scheme ensuring that a consumer's car battery is not impairedunder normal operating conditions. This can include battery backupsupport when the vehicle is off in order to support various wake-up andkeep-alive tasks. All data collected subsequent to the last acknowledgeddownload can be maintained in non-volatile memory until the apparatus isreconnected to an external power source. At that point, the apparatuscan self re-initialize and resume normal operation. Specific batterychemistry can optimize life/charge cycles. The battery can berechargeable. The battery can be user replaceable or non-userreplaceable.

The apparatus 101 can receive power from power supply 114. The powersupply can have many unique features necessary for correct operationwithin the automotive environment. One mode is to supple a small amountof power (typically less than 100 microamps) to at least one mastercontroller that can control all the other power buses inside of the VTU101. In an exemplary system, a low power low dropout linear regulatorsupplies this power to PCS/Cellular modem 102. This provides the staticpower to maintain internal functions so that it can await external userpush-button inputs or await CAN activity via vehicle interface 111. Uponreceipt of an external stimulus via either a manual push button or CANactivity, the processor contained within the PCS/Cellular modem 102 cancontrol the power supply 114 to activate other functions within the VTU101, such as GPS 104/GYRO 105, Processor 106/Memory 107 and 108, SDARSreceiver 103, audio/video entertainment system 109, audio codec mux 110,and any other peripheral within the VTU 101 that does not requirestandby power.

In an exemplary system, there can be a plurality of power supply states.One state can be a state of full power and operation, selected when thevehicle is operating. Another state can be a full power relying onbattery backup. It can be desirable to turn off the GPS and any othernon-communication related subsystem while operating on the back-upbatteries.

Another state can be when the vehicle has been shut off recently,perhaps within the last 30 days, and the system maintains communicationswith a two-way wireless network for various auxiliary services likeremote door unlocking and location determination messages. After therecent shut down period, it is desirable to conserve the vehicle batteryby turning off almost all power except the absolute minimum in order tomaintain system time of day clocks and other functions, waiting to beawakened on CAN activity. Additional power states are contemplated, suchas a low power wakcup to check for network messages, but these arenonessential features to the operation of the VTU.

Normal operation can comprise, for example, the PCS/Cellular modem 102waiting for an emergency pushbutton key-press or CAN activity. Onceeither is detected, the PCS/Cellular modem 102 can awaken and enable thepower supply 114 as required. Shutdown can be similar wherein a firstlevel shutdown turns off everything except the PCS/Cellular modem 102,for example. The PCS/Cellular modem 102 can maintain wireless networkcontact during this state of operation. The VTU 101 can operate normallyin the state when the vehicle is turned off. If the vehicle is off foran extended period of time, perhaps over a vacation etc., thePCS/Cellular modem 102 can be dropped to a very low power state where itno longer maintains contact with the wireless network.

Additionally, in FIG. 1, subsystems can include a BlueTooth transceiver115 that can be provided to interface with devices such as phones,headsets, music players, and telematics user interfaces. The apparatuscan comprise one or more user inputs, such as emergency button 117 andnon-emergency button 118. Emergency button 117 can be coupled to theprocessor 106. The emergency button 117 can be located in a vehiclecockpit and activated an occupant of the vehicle. Activation of theemergency button 117 can cause processor 106 to initiate a voice anddata connection from the vehicle to a central monitoring station, alsoreferred to as a remote call center. Data such as GPS location andoccupant personal information can be transmitted to the call center. Thevoice connection permits two way voice communication between a vehicleoccupant and a call center operator. The call center operator can havelocal emergency responders dispatched to the vehicle based on the datareceived. In another embodiment, the connections are made from thevehicle to an emergency responder center.

One or more non-emergency buttons 118 can be coupled to the processor106. One or more non-emergency buttons 118 can be located in a vehiclecockpit and activated by an occupant of the vehicle. Activation of theone or more non-emergency buttons 118 can cause processor 106 toinitiate a voice and data connection from the vehicle to a remote callcenter. Data such as GPS location and occupant personal information canbe transmitted to the call center. The voice connection permits two wayvoice communications between a vehicle occupant and a call centeroperator. The call center operator can provide location based servicesto the vehicle occupant based on the data received and the vehicleoccupant's desires. For example, a button can provide a vehicle occupantwith a link to roadside assistance services such as towing, spare tirechanging, refueling, and the like. In another embodiment, a button canprovide a vehicle occupant with concierge-type services, such as localrestaurants, their locations, and contact information; local serviceproviders their locations, and contact information; travel relatedinformation such as flight and train schedules; and the like.

For any voice communication made through the VTU 101, text-to-speechalgorithms can be used so as to convey predetermined messages inaddition to or in place of a vehicle occupant speaking. This allows forcommunication when the vehicle occupant is unable or unwilling tocommunicate vocally.

In an aspect, apparatus 101 can be coupled to a telematics userinterface located remote from the apparatus. For example, the telematicsuser interface can be located in the cockpit of a vehicle in view ofvehicle occupants while the apparatus 101 is located under thedashboard, behind a kick panel, in the engine compartment, in the trunk,or generally out of sight of vehicle occupants.

FIG. 2 illustrates an exemplary apparatus for connection to an OBD IIport. FIG. 2 illustrates an exemplary apparatus comprising one externalwire for connection to the OBD II port, and a built-in antenna. In oneaspect, the apparatuses can be as small as possible according tocustomer preferences and engineering capabilities. The apparatuses canhave display functions such as LEDs, and the like. The apparatuses canbe small and unobtrusive to a vehicle operator. The apparatuses can beeasily installed and removed by end customers with average technicalability. The apparatuses can tolerate shock from most automobileaccidents and reasonable impacts.

FIG. 3 is a block diagram illustrating an exemplary driver behaviordetermination system 300 showing network connectivity between variouscomponents. The driver behavior determination system 300 can comprise aVTU 101 located in a motor vehicle 301. The driver behaviordetermination system 300 can comprise a central monitoring station 302.The central monitoring station 302 can serve as a market specific datagatekeeper. That is, users 303 can pull information from specific,multiple or all markets at any given time for immediate analysis. Thedistributed computing model has no single point of complete systemfailure, thus minimizing driver behavior determination system 300downtime. In an embodiment, central monitoring station 302 cancommunicate through an existing communications network (e.g., wirelesstowers 304 and communications network 305). Driver behaviordetermination system 300 can comprise at least one satellite 306 fromwhich GPS data are determined. These signals can be received by a GPSreceiver in the vehicle 301.

The driver behavior determination system 300 can comprise a plurality ofusers 303 (insurance companies, governments, individuals, and the like)which can access driver behavior determination system 300 using acomputer or other such computing device, running a commerciallyavailable Web browser or client software. For simplicity, FIG. 3 showsonly one user 303. The users 303 can connect to the driver behaviordetermination system 300 via the communications network 305. In anembodiment, communications network 305 can comprise the Internet.

The driver behavior determination system 300 can comprise a centralmonitoring station 302 which can comprise one or more central monitoringstation servers. In some aspects, one or more central monitoring stationservers can serve as the “back-bone” (i.e., system processing) of thepresent driver behavior determination system 300. One skilled in the artwill appreciate that driver behavior determination system 300 canutilize servers (and databases) physically located on one or morecomputers and at one or more locations. Central monitoring stationserver can comprise software code logic that is responsible for handlingtasks such as data interpretations, statistics processing, datapreparation and compression for output to VTU 101, and application ofunderwriting guidelines, behavior determination, and driving reportgeneration for output to users 303. In an embodiment, user 303 can hosta server (also referred to as a remote host) that can perform similarfunctions as a central monitoring station server. In an embodiment ofthe present driver behavior determination system 300, central monitoringstation servers and/or remote host servers, can have access to arepository database which can be a central store for all information andvehicle performance data within the driver behavior determination system300 (e.g., executable code, subscriber information such as login names,passwords, etc., and vehicle and demographics related data). Centralmonitoring station servers and/or a remote host server can also providea “front-end” for the driver behavior determination system 300. That is,a central monitoring station server can comprise a Web server forproviding a Web site which sends out Web pages in response to requestsfrom remote browsers (i.e., users 303 or customers of users 303). Morespecifically, a central monitoring station server and/or a remote hostserver can provide a graphical user interface (GUI) “front-end” to users303 of the driver behavior determination system 300 in the form of Webpages. These Web pages, when sent to the user PC (or the like), canresult in GUI screens being displayed.

Provided is a dynamic means for presenting location and diagnostics datato consumers in a useful and attractive format. Users/consumers canactively monitor their vehicle's location, speed history, stop history,vehicle health, driving report, etc. . . . through a web-interface. Anyor all of the data generated by the features described above includingbut not limited to, diagnostics and monitored driver behavior can beuploaded to the interne, stored for display on a web-site, and/or sentto the vehicle owner (or other approved party) via and e-mail or textmessage (SMS). An exemplary interface is illustrated in FIG. 4.

In one aspect, an exemplary flow and operation of the driver behaviordetermination system 300 can be as follows: After a pre-determined timeinterval (e.g., a time interval measured in days, hours, minutes, etc.)of monitoring and recording vehicle performance data, the VTU 101 canprepare stored vehicle performance data for transmission as one or morepackets. A packet can be sent via a wireless link to central monitoringstation 302 through communications network 305. There, the vehicleperformance data can be processed (i.e., compiled and analyzed) by aserver. In another embodiment, the vehicle performance data can beprocessed (i.e., compiled and analyzed) by the VTU 101 and processeddata can be transmitted to central monitoring station 302. The processedperformance data can then be made ready for distribution (i.e., reportsgenerated by server) to users 303. The VTU 301 may be configured totransmit vehicle performance data collected from the vehicle withvarying frequency (e.g., once every 5 minutes, twice a day, etc.). Suchfrequency can depend on factors such as the size of the memory of theVTU 101, bandwidth of the communications network 305, needs of the users303, and the like.

In an aspect, the VTU 101 can transmit vehicle performance data upon atriggering event such as, but not limited to vehicle crash indication,acceleration above a threshold, speed above a threshold, and the like.VTU 101 transmission of vehicle performance data packets can be on anyof a fixed time basis, fixed amount of data basis, or fixed event basisand can be downloadable from a central monitoring station server and/orwebsite.

As described above, VTU 101 can communicate with one or more computers,either through direct wireless communication and/or through a networksuch as the Internet. Such communication can facilitate data transfer,voice communication, and the like. One skilled in the art willappreciate that what follows is a functional description of an exemplarycomputing device and that various functions can be performed bysoftware, by hardware, or by any combination of software and hardware.

FIG. 5 is a block diagram illustrating an exemplary operatingenvironment for performing the disclosed methods, for example, a server,or other computing device, at a remote host or a central monitoringstation. This exemplary operating environment is only an example of anoperating environment and is not intended to suggest any limitation asto the scope of use or functionality of operating environmentarchitecture. Neither should the operating environment be interpreted ashaving any dependency or requirement relating to any one or combinationof components illustrated in the exemplary operating environment.

The methods and systems can be operational with numerous other generalpurpose or special purpose computing system environments orconfigurations. Examples of well known computing systems, environments,and/or configurations that can be suitable for use with the system andmethod comprise, but are not limited to, personal computers, servercomputers, laptop devices, and multiprocessor systems. Additionalexamples comprise set top boxes, programmable consumer electronics,network PCs, minicomputers, mainframe computers, distributed computingenvironments that comprise any of the above systems or devices, and thelike.

In another aspect, the methods and systems can be described in thegeneral context of computer instructions, such as program modules, beingexecuted by a computer. Generally, program modules comprise routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Themethods and systems can also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules can be located in both local and remotecomputer storage media including memory storage devices.

Further, one skilled in the art will appreciate that the systems andmethods disclosed herein can be implemented via a general-purposecomputing device in the form of a computer 501. The components of thecomputer 501 can comprise, but are not limited to, one or moreprocessors or processing units 503, a system memory 512, and a systembus 513 that couples various system components including the processor503 to the system memory 512.

The system bus 513 represents one or more of several possible types ofbus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, and a processor or localbus using any of a variety of bus architectures. By way of example, sucharchitectures can comprise an Industry Standard Architecture (ISA) bus,a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, aVideo Electronics Standards Association (VESA) local bus, an AcceleratedGraphics Port (AGP) bus, and a Peripheral Component Interconnects (PCI)bus, PCI-Express bus, Universal Serial Bus (USB), and the like. The bus513, and all buses specified in this description can also be implementedover a wired or wireless network connection and each of the subsystems,including the processor 503, a mass storage device 504, an operatingsystem 505, telematics software 506, vehicle performance data 507, anetwork adapter (or communications interface) 508, system memory 512, anInput/Output Interface 510, a display adapter 509, a display device 511,and a human machine interface 502, can be contained within one or moreremote computing devices 514 a,b,c at physically separate locations,connected through buses of this form, in effect implementing a fullydistributed system. In one aspect, a remote computing device can be aVTU 101.

The computer 501 typically comprises a variety of computer readablemedia. Exemplary readable media can be any available media that isaccessible by the computer 501 and comprises, for example and not meantto be limiting, both volatile and non-volatile media, removable andnon-removable media. The system memory 512 comprises computer readablemedia in the form of volatile memory, such as random access memory(RAM), and/or non-volatile memory, such as read only memory (ROM). Thesystem memory 512 typically contains data such as vehicle performancedata 507 and/or program modules such as operating system 505 and vehicleperformance data processing software 506 that are immediately accessibleto and/or are presently operated on by the processing unit 503. Vehicleperformance data 507 can comprise any data generated by, generated for,received from, or sent to the VTU 101.

In another aspect, the computer 501 can also comprise otherremovable/non-removable, volatile/non-volatile computer storage media.By way of example, FIG. 5 illustrates a mass storage device 504 whichcan provide non-volatile storage of computer code, computer readableinstructions, data structures, program modules, and other data for thecomputer 501. For example and not meant to be limiting, a mass storagedevice 504 can be a hard disk, a removable magnetic disk, a removableoptical disk, magnetic cassettes or other magnetic storage devices,flash memory cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, random access memories (RAM), read only memories (ROM),electrically erasable programmable read-only memory (EEPROM), and thelike.

Optionally, any number of program modules can be stored on the massstorage device 504, including by way of example, an operating system 505and vehicle performance data processing software 506. Each of theoperating system 505 and vehicle performance data processing software506 (or some combination thereof) can comprise elements of theprogramming and the vehicle performance data processing software 506.Vehicle performance data 507 can also be stored on the mass storagedevice 504. Vehicle performance data 507 can be stored in any of one ormore databases known in the art. Examples of such databases comprise,DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL,PostgreSQL, and the like. The databases can be centralized ordistributed across multiple systems.

In another aspect, the user can enter commands and information into thecomputer 501 via an input device (not shown). Examples of such inputdevices comprise, but are not limited to, a keyboard, pointing device(e.g., a “mouse”), a microphone, a joystick, a scanner, tactile inputdevices such as gloves, and other body coverings, and the like These andother input devices can be connected to the processing unit 503 via ahuman machine interface 502 that is coupled to the system bus 513, butcan be connected by other interface and bus structures, such as aparallel port, game port, an IEEE 1394 Port (also known as a Firewireport), a serial port, or a universal serial bus (USB).

In yet another aspect, a display device 511 can also be connected to thesystem bus 513 via an interface, such as a display adapter 509. It iscontemplated that the computer 501 can have more than one displayadapter 509 and the computer 501 can have more than one display device511. For example, a display device can be a monitor, an LCD (LiquidCrystal Display), or a projector. In addition to the display device 511,other output peripheral devices can comprise components such as speakers(not shown) and a printer (not shown) which can be connected to thecomputer 501 via Input/Output Interface 510. Any step and/or result ofthe methods can be output in any form to an output device. Such outputcan be any form of visual representation, including, but not limited to,textual, graphical, animation, audio, tactile, and the like.

The computer 501 can operate in a networked environment using logicalconnections to one or more remote computing devices 514 a,b,c. By way ofexample, a remote computing device can be a personal computer, portablecomputer, a server, a router, a network computer, a VTU 101, a PDA, acellular phone, a “smart” phone, a wireless communications enabled keyfob, a peer device or other common network node, and so on. Logicalconnections between the computer 501 and a remote computing device 514a,b,c can be made via a local area network (LAN) and a general wide areanetwork (WAN). Such network connections can be through a network adapter508. A network adapter 508 can be implemented in both wired and wirelessenvironments. Such networking environments are conventional andcommonplace in offices, enterprise-wide computer networks, intranets,and the Internet 515. In one aspect, the remote computing device 514a,b,c can be one or more VTU 101's.

For purposes of illustration, application programs and other executableprogram components such as the operating system 505 are illustratedherein as discrete blocks, although it is recognized that such programsand components reside at various times in different storage componentsof the computing device 501, and are executed by the data processor(s)of the computer. An implementation of vehicle performance dataprocessing software 506 can be stored on or transmitted across some formof computer readable media. Computer readable media can be any availablemedia that can be accessed by a computer. By way of example and notmeant to be limiting, computer readable media can comprise “computerstorage media” and “communications media.” “Computer storage media”comprise volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules, orother data. Exemplary computer storage media comprises, but is notlimited to, RAM, ROM, EEPROM, flash memory or other memory technology,CD-ROM, digital versatile disks (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store thedesired information and which can be accessed by a computer.

The processing of the disclosed methods and systems can be performed bysoftware components. The disclosed system and method can be described inthe general context of computer-executable instructions, such as programmodules, being executed by one or more computers or other devices.Generally, program modules comprise computer code, routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. The disclosed methods canalso be practiced in grid-based and distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules can be located in both local and remotecomputer storage media including memory storage devices.

Predicting driver behavior is important to the insurance industry aswell as any business that operates a fleet of vehicles and is concernedabout driver behavior liability.

Detection of an actual crash event absent a connection to the internalbusses of a vehicle can be challenging. Even with the use ofaccelerometers—which have their own unique set of challenges rangingfrom installation issues to false positives—crash determination withoutthe presence of a two-way voice connection for confirmation isproblematic.

Provided are methods, systems, and apparatuses for determining a“probability” of a crash, which leverages vehicle data to predict driverbehavior. Any available method for accessing a vehicle data bus can beused. For example, a vehicle's OBD data stream can be used toextrapolate key data points indicating that a crash may have occurred.For example, these methods can rely on a rapid drop in OBD II speed froma pre-determined threshold to zero in a short period of time.

Frequent readings (in some aspects, as often as 1 second) of OBD IIspeed can determine many aspects of driver behavior in addition to acrash, for example, rapid acceleration & rapid deceleration, slowacceleration & slow deceleration, unpredictable acceleration &deceleration patterns, successive acceleration & deceleration cycles,and determining a driver identity by mapping speed patterns into asignature.

Just as frequent readings (in some aspects, as often as 1 second) of OBDII speed can be a cost-effective way to monitor and measure driverbehavior, frequent readings of GPS location and/or speed can augmentthis scenario.

Frequent GPS readings (in some aspects, as often as 1 second) can alsobe used to create a moving scatter diagram within the 3 meter resolutionof a standard GPS system (approximately the width of a standard roadwaydriving lane) to determine lane changing behavior slow lane change(riding the dividing line), rapid lane change (abrupt lateral movement),frequent lane change, traveling too slowly for the appropriate lane,moving faster than speed limit (if speed limit of roadway is known),traveling below minimum legal speed for a roadway, and determining adriver identity by mapping GPS patterns into a signature.

In an aspect, illustrated in FIG. 6, provided are methods fordetermining driver behavior, comprising receiving vehicle performancedata at 601, determining a driver safety metric based on the vehicleperformance data at 602, and transmitting the safety metric to a remotehost at 603. A safety metric can be any indication of driving behaviorsafety. For example, a safety metric can be a categorization of drivingbehavior, a safety metric can be an insurance premium, a safety metriccan be processed vehicle performance data, and the like.

The methods can be performed on an in-vehicle apparatus, at a centralmonitoring station, at a remote host, and combinations thereof. Themethods can further comprise outputting a visual representation of thesafety metric to a display device.

Vehicle performance data can comprise one or more of, acceleration,acceleration time, acceleration frequency, location of acceleration,deceleration, deceleration time, deceleration frequency, location ofdeceleration, speed, location of speed, lane change, speed of lanechange, frequency of lane change, location of lane change, weather,weather during acceleration, weather during deceleration, weather duringspeed, weather during lane change, time of day, acceleration time ofday, deceleration time of day, speed time of day, lane change time ofday, telephone usage, timing of telephone usage, vehicle entertainmentsystem usage, timing of vehicle entertainment system usage, vehicleoccupancy, and seatbelt usage. These vehicle performance data can beindicative of driver behavior. These data can be obtained though avehicle diagnostic port and through a combination of the vehiclediagnostic report and GPS location data. The vehicle performance dataindicate driving behavior when considered alone, or in combination withother vehicle performance data. For example, a driver traveling at 50miles per hour could be considered safe, but a driver traveling 50 milesper hour without a safety belt engaged and while traveling on a roadwith a known speed limit of 25 miles per hour can be considered unsafe.One skilled in the art can appreciate the variety of combinations ofvehicle performance data and the driving behavior indicated. Any and allcombinations of such vehicle performance data are specificallycontemplated. The vehicle performance data can comprise personalidentification data. The personal identification data can comprise aVehicle Identification Number (VIN).

Receiving vehicle performance data can comprise receiving vehicleperformance data at an in-vehicle apparatus and transmitting the vehicleperformance data to a central monitoring station.

Determining a driver safety metric based on the vehicle performance datacan comprise analyzing the vehicle performance data to determine one ormore behaviors. For example, a driver interacting with the vehicleentertainment system while traveling over the speed limit and performingabrupt lane changes can be considered an unsafe driver.

Analyzing the vehicle performance data to determine one or morebehaviors can comprise applying third party underwriting guidelines.Insurance companies are permitted to implement rates by grouping theirinsured into categories, each category paying different rates dependingupon the nature of the category. Insurance companies develop andmaintain underwriting guidelines or rules which define the nature of therating categories and describe the differences between the categories.In one aspect, the methods, systems, and apparatuses provided canutilize an insurance company's existing underwriting guidelines, ornewly created guidelines that take advantage of the detailed drivingbehavior information provided. In another aspect, the methods, systems,and apparatuses provided can categorize driving behavior without regardto a third party underwriting guideline. Analyzing the vehicleperformance data to determine one or more behaviors can comprisecategorizing vehicle performance into a plurality of risk strata. Theplurality of risk strata can comprise safe, unsafe, and aggressive. Forexample, the methods, systems, and apparatuses can analyze vehicleperformance data, categorize driver behavior, and provide thiscategorization to a third party, such as an insurance company, a vehicleowner, a vehicle driver, and the like.

The methods can further comprise generating a driving report based onthe vehicle performance data and providing the driving report to a userthrough a website. Either the central monitoring station, the remotehost, or both, can provide such a website.

In order for the methods, systems, and apparatuses to function properly,it is advantageous to ascertain whether the apparatus is properlyinstalled, functioning, and that it is not being periodically removedfrom a monitored vehicle or moved from vehicle to vehicle. Provided aremethods for detecting events of device removal and attempted fraud basedon vehicle emissions status and monitor status.

A serial number for the apparatus can be stored in apparatus memoryalong with a vehicle identification number (VIN) intended to beassociated with the serial number. Periodically, the apparatus canretrieve, through a vehicle bus, a VIN of the vehicle in which theapparatus is installed. The apparatus can compare the stored VIN to theretrieved VIN. If there is a discrepancy, the apparatus can perform oneor more fraud actions. Fraud actions can include, but are not limitedto, reporting the results of the comparison to a central monitoringstation, terminating monitoring activity, and the like.

In another aspect, illustrated in FIG. 7, provided are methods forinsurance premium adjustment, comprising receiving vehicle performancedata at 701, analyzing the vehicle performance data to determine one ormore behaviors at 702, and adjusting an insurance premium based on theone or more behaviors at 703. The methods can further compriseoutputting a visual representation of the insurance premium to a displaydevice. The methods can further comprise generating a driving reportbased on the vehicle performance data and providing the driving reportto a user through a website.

Vehicle performance data can comprise one or more of, acceleration,acceleration time, acceleration frequency, location of acceleration,deceleration, deceleration time, deceleration frequency, location ofdeceleration, speed, location of speed, lane change, speed of lanechange, frequency of lane change, location of lane change, weather,weather during acceleration, weather during deceleration, weather duringspeed, weather during lane change, time of day, acceleration time ofday, deceleration time of day, speed time of day, lane change time ofday, telephone usage, timing of telephone usage, vehicle entertainmentsystem usage, timing of vehicle entertainment system usage, vehicleoccupancy, and seatbelt usage. These vehicle performance data can beindicative of driver behavior. These data can be obtained though avehicle diagnostic port and through a combination of the vehiclediagnostic report and GPS location data. The vehicle performance dataindicate driving behavior when considered alone, or in combination withother vehicle performance data. For example, a driver traveling at 50miles per hour could be considered safe, but a driver traveling 50 milesper hour without a safety belt engaged and while traveling on a roadwith a known speed limit of 25 miles per hour can be considered unsafe.One skilled in the art can appreciate the variety of combinations ofvehicle performance data and the driving behavior indicated. Any and allcombinations of such vehicle performance data are specificallycontemplated. The vehicle performance data can comprise personalidentification data. The personal identification data can comprise aVehicle Identification Number (VIN). Transmitted vehicle performancedata can be received and processed at a central monitoring station.

Determining a driver safety metric based on the vehicle performance datacan comprise analyzing the vehicle performance data to determine one ormore behaviors. For example, a driver interacting with the vehicleentertainment system while traveling over the speed limit and performingabrupt lane changes can be considered an unsafe driver.

Analyzing the vehicle performance data to determine one or morebehaviors can comprise applying third party underwriting guidelines.Insurance companies are permitted to implement rates by grouping theirinsured into categories, each category paying different rates dependingupon the nature of the category. Insurance companies develop andmaintain underwriting guidelines or rules which define the nature of therating categories and describe the differences between the categories.In one aspect, the methods, systems, and apparatuses provided canutilize an insurance company's existing underwriting guidelines, ornewly created guidelines that take advantage of the detailed drivingbehavior information provided. In another aspect, the methods, systems,and apparatuses provided can categorize driving behavior without regardto a third party underwriting guideline. Analyzing the vehicleperformance data to determine one or more behaviors can comprisecategorizing vehicle performance into a plurality of risk strata. Theplurality of risk strata can comprise safe, unsafe, and aggressive. Forexample, the methods, systems, and apparatuses can analyze vehicleperformance data, categorize driver behavior, and provide thiscategorization to a third party, such as an insurance company, a vehicleowner, a vehicle driver, and the like.

In an aspect, illustrated in FIG. 8, provided are methods for frauddetection, comprising retrieving a vehicle identification parameterthrough a vehicle bus at 801, comparing the retrieved vehicleidentification parameter with a stored vehicle identification profile at802, and performing a fraud action based on the comparison at 803. Thevehicle identification parameter can be, for example, a vehicleidentification number (VIN), one or more vehicle operating parameters,and combinations thereof. Vehicle operating parameters can vary betweenvehicles. For example, vehicle operating parameters of a sports car canbe much different than that of an economy car. For example, idle speed,fuel economy, and the like. The methods, systems, and apparatuses cancreate a vehicle identification profile based on monitored vehicleoperating parameters over time while installed in a vehicle andregularly compare current vehicle operating parameters to the profile.The vehicle identification profile can also comprise the VIN of thevehicle in which the apparatus is intended to be installed. If theapparatus is moved to another vehicle, it can be determined if the newvehicle operating parameters and/or VIN differ from the vehicleidentification profile, thereby causing a fraud action to be performed.The fraud action can comprise reporting the results of the comparison toa central monitoring station, terminating monitoring activity, and thelike.

In another aspect, illustrated in FIG. 9, provided is an apparatus fordriver behavior determination, comprising a vehicle interface 901,coupled to a vehicle bus 902, wherein the vehicle interface 901 isconfigured to receive vehicle performance data through the vehicle bus902, a wireless transceiver 903, configured for transmitting the vehicleperformance data, and a processor 904, coupled to the vehicle interface901 and the wireless transceiver 903, wherein the processor 904 iswherein the processor is configured for receiving the vehicleperformance data from the vehicle interface 901, determining a driversafety metric based on the vehicle performance data, and for providingthe driver safety metric to the wireless transceiver 903. The apparatuscan further comprise a GPS transceiver coupled to the processor 904. Theapparatus can further comprise an output device coupled to the processor904, configured for displaying a visual representation of the safetymetric. The wireless transceiver 903 can be configured for transmittingthe vehicle performance data to a remote host. The wireless transceiver903 can be is configured for transmitting the vehicle performance datato a central monitoring station. In another aspect, the apparatus can befurther configured for performing the methods disclosed herein forperforming fraud detection. In yet another aspect, the apparatus can befurther configured for performing the methods disclosed herein forinsurance premium adjustment.

Vehicle performance data can comprise one or more of, acceleration,acceleration time, acceleration frequency, location of acceleration,deceleration, deceleration time, deceleration frequency, location ofdeceleration, speed, location of speed, lane change, speed of lanechange, frequency of lane change, location of lane change, weather,weather during acceleration, weather during deceleration, weather duringspeed, weather during lane change, time of day, acceleration time ofday, deceleration time of day, speed time of day, lane change time ofday, telephone usage, timing of telephone usage, vehicle entertainmentsystem usage, timing of vehicle entertainment system usage, vehicleoccupancy, and seatbelt usage. These vehicle performance data can beindicative of driver behavior. These data can be obtained though avehicle diagnostic port and through a combination of the vehiclediagnostic report and GPS location data. The vehicle performance dataindicate driving behavior when considered alone, or in combination withother vehicle performance data. For example, a driver traveling at 50miles per hour could be considered safe, but a driver traveling 50 milesper hour without a safety belt engaged and while traveling on a roadwith a known speed limit of 25 miles per hour can be considered unsafe.One skilled in the art can appreciate the variety of combinations ofvehicle performance data and the driving behavior indicated. Any and allcombinations of such vehicle performance data are specificallycontemplated. The vehicle performance data can comprise personalidentification data. The personal identification data can comprise aVehicle Identification Number (VIN). Transmitted vehicle performancedata can be received and processed at a central monitoring station.

Determining a driver safety metric based on the vehicle performance datacan comprise analyzing the vehicle performance data to determine one ormore behaviors. For example, a driver interacting with the vehicleentertainment system while traveling over the speed limit and performingabrupt lane changes can be considered an unsafe driver.

Analyzing the vehicle performance data to determine one or morebehaviors can comprise applying third party underwriting guidelines.Insurance companies are permitted to implement rates by grouping theirinsured into categories, each category paying different rates dependingupon the nature of the category. Insurance companies develop andmaintain underwriting guidelines or rules which define the nature of therating categories and describe the differences between the categories.In one aspect, the methods, systems, and apparatuses provided canutilize an insurance company's existing underwriting guidelines, ornewly created guidelines that take advantage of the detailed drivingbehavior information provided. In another aspect, the methods, systems,and apparatuses provided can categorize driving behavior without regardto a third party underwriting guideline. Analyzing the vehicleperformance data to determine one or more behaviors can comprisecategorizing vehicle performance into a plurality of risk strata. Theplurality of risk strata can comprise safe, unsafe, and aggressive. Forexample, the methods, systems, and apparatuses can analyze vehicleperformance data, categorize driver behavior, and provide thiscategorization to a third party, such as an insurance company, a vehicleowner, a vehicle driver, and the like.

The transmitted vehicle performance data can be processed to determinedriver behavior, driver risk category, associated insurance premiumadjustments, and combinations thereof. The apparatus can be configuredto receive an indication of driving behavior based on the vehicleperformance data. The indication of driving behavior can be displayed tothe driver of the vehicle on one or more output devices. For example, awarning (or compliment) can be provided to the driver on a displayscreen in the vehicle cockpit, one or more LEDs on the instrumentcluster can indicate driving behavior, and the like.

In some aspects, the wireless transceiver 903 can be configured totransmit the vehicle performance data based on a triggering event. Thetriggering event can comprise one or more of, vehicle crash indication,acceleration above a threshold, speed above a threshold, and the like.The wireless transceiver 903 can be configured to transmit the vehicleperformance data based on one or more of, a fixed time basis, fixedamount of data basis, or fixed event basis.

In another aspect, illustrated in FIG. 10, provided is a system fordriver behavior determination, comprising a telematics device 1001,configured for receiving vehicle performance data through a vehicle busand transmitting the vehicle performance data and a central monitoringstation 1002, configured for receiving the vehicle performance data,determining a driver safety metric based on the vehicle performancedata, and transmitting the safety metric to a remote host. The centralmonitoring station 1002 can be further configured for outputting avisual representation of the safety metric to a display device. Inanother aspect, the system can be further configured for performing themethods disclosed herein for performing fraud detection. In yet anotheraspect, the system can be further configured for performing the methodsdisclosed herein for insurance premium adjustment.

Vehicle performance data can comprise one or more of acceleration,acceleration time, acceleration frequency, location of acceleration,deceleration, deceleration time, deceleration frequency, location ofdeceleration, speed, location of speed, lane change, speed of lanechange, frequency of lane change, location of lane change, weather,weather during acceleration, weather during deceleration, weather duringspeed, weather during lane change, time of day, acceleration time ofday, deceleration time of day, speed time of day, lane change time ofday, telephone usage, timing of telephone usage, vehicle entertainmentsystem usage, timing of vehicle entertainment system usage, vehicleoccupancy, and seatbelt usage. These vehicle performance data can beindicative of driver behavior. These data can be obtained though avehicle diagnostic port and through a combination of the vehiclediagnostic report and GPS location data. The vehicle performance dataindicate driving behavior when considered alone, or in combination withother vehicle performance data. For example, a driver traveling at 50miles per hour could be considered safe, but a driver traveling 50 milesper hour without a safety belt engaged and while traveling on a roadwith a known speed limit of 25 miles per hour can be considered unsafe.One skilled in the art can appreciate the variety of combinations ofvehicle performance data and the driving behavior indicated. Any and allcombinations of such vehicle performance data are specificallycontemplated. The vehicle performance data can comprise personalidentification data. The personal identification data can comprise aVehicle Identification Number (VIN). Transmitted vehicle performancedata can be received and processed at a central monitoring station.

Determining a driver safety metric based on the vehicle performance datacan comprise analyzing the vehicle performance data to determine one ormore behaviors. For example, a driver interacting with the vehicleentertainment system while traveling over the speed limit and performingabrupt lane changes can be considered an unsafe driver.

Analyzing the vehicle performance data to determine one or morebehaviors can comprise applying third party underwriting guidelines.Insurance companies are permitted to implement rates by grouping theirinsured into categories, each category paying different rates dependingupon the nature of the category. Insurance companies develop andmaintain underwriting guidelines or rules which define the nature of therating categories and describe the differences between the categories.In one aspect, the methods, systems, and apparatuses provided canutilize an insurance company's existing underwriting guidelines, ornewly created guidelines that take advantage of the detailed drivingbehavior information provided. In another aspect, the methods, systems,and apparatuses provided can categorize driving behavior without regardto a third party underwriting guideline. Analyzing the vehicleperformance data to determine one or more behaviors can comprisecategorizing vehicle performance into a plurality of risk strata. Theplurality of risk strata can comprise safe, unsafe, and aggressive. Forexample, the methods, systems, and apparatuses can analyze vehicleperformance data, categorize driver behavior, and provide thiscategorization to a third party, such as an insurance company, a vehicleowner, a vehicle driver, and the like.

The transmitted vehicle performance data can be processed to determinedriver behavior, driver risk category, associated insurance premiumadjustments, and combinations thereof. The apparatus can be configuredto receive an indication of driving behavior based on the vehicleperformance data. The indication of driving behavior can be displayed tothe driver of the vehicle on one or more output devices. For example, awarning (or compliment) can be provided to the driver on a displayscreen in the vehicle cockpit, one or more LEDs on the instrumentcluster can indicate driving behavior, and the like.

The central monitoring station can be configured to transmit anindication of driving behavior based on the vehicle performance data.The indication of driving behavior can be displayed to the driver of thevehicle on one or more output devices. For example, a warning (orcompliment) can be provided to the driver on a display screen in thevehicle cockpit, one or more LEDs on the instrument cluster can indicatedriving behavior, and the like.

The telematics device can be configured to transmit the vehicle driverbehavior determination data based on a triggering event. The triggeringevent can comprise one or more of vehicle crash indication, accelerationabove a threshold, speed above a threshold, and the like. The telematicsdevice can be configured to transmit the vehicle driver behaviordetermination data based on one or more of, a fixed time basis, fixedamount of data basis, or fixed event basis.

The central monitoring station 1002, the remote host, or both, can beconfigured to generate a driving report based on the vehicle performancedata and providing the driving report to a user through a website.

While the methods, systems, and apparatuses have been described inconnection with preferred embodiments and specific examples, it is notintended that the scope be limited to the particular embodiments setforth, as the embodiments herein are intended in all respects to beillustrative rather than restrictive.

Unless otherwise expressly stated, it is in no way intended that anymethod set forth herein be construed as requiring that its steps beperformed in a specific order. Accordingly, where a method claim doesnot actually recite an order to be followed by its steps or it is nototherwise specifically stated in the claims or descriptions that thesteps are to be limited to a specific order, it is no way intended thatan order be inferred, in any respect. This holds for any possiblenon-express basis for interpretation, including: matters of logic withrespect to arrangement of steps or operational flow; plain meaningderived from grammatical organization or punctuation; the number or typeof embodiments described in the specification.

It will be apparent to those skilled in the art that variousmodifications and variations can be made without departing from thescope or spirit. Other embodiments will be apparent to those skilled inthe art from consideration of the specification and practice disclosedherein. It is intended that the specification and examples be consideredas exemplary only, with a true scope and spirit being indicated by thefollowing claims.

1-47. (canceled)
 48. A method for detecting that a vehicle has beenstolen, comprising: retrieving, over a predetermined period, by atelematics device coupled to a data bus of the vehicle, datacorresponding to at least one vehicle parameter; evaluating the datacorresponding to the at least one vehicle parameter retrieved over thepredetermined period; generating, by the telematics device, a vehicleidentification profile based on the evaluating of the data retrievedover the predetermined period; storing the vehicle identificationprofile to a memory of the telematics device; comparing currentretrieved vehicle data with the stored vehicle identification profile;determining, by the telematics device, whether a driver not associatedwith the vehicle drove the vehicle when the current retrieved vehicledata was retrieved if the current retrieved vehicle data does notsubstantially match one, or more, stored vehicle identification profile,or profiles; and performing a fraud action if a driver not associatedwith the vehicle was driving the vehicle when the current retrievedvehicle data was retrieved.
 49. The method of claim 48, wherein thevehicle parameter comprises one or more of vehicle operating parameters,a vehicle identification number (VIN), or combinations thereof.
 50. Themethod of claim 48, wherein performing a fraud action comprisesreporting the results of the comparison to a central monitoring station.51. The method of claim 50, wherein performing a fraud action comprisessending an alert from the central monitoring station to an interestedparty, wherein an interested party includes the owner of the vehicle.52. A telematics device configured to perform the steps of a method fordetecting a stolen vehicle, the method comprising: retrieving, over apredetermined period, data corresponding to at least one vehicleparameter; evaluating the data corresponding to the at least one vehicleparameter retrieved over the predetermined period; generating a vehicleidentification profile based on the evaluating of the data retrievedover the predetermined period; storing the vehicle identificationprofile to a memory of the telematics device; comparing currentretrieved vehicle data with the stored vehicle identification profile;determining whether a driver not associated with the vehicle drove thevehicle when the current retrieved vehicle data was retrieved if thecurrent retrieved vehicle data does not substantially match one, ormore, stored vehicle identification profile, or profiles; and performinga fraud action if a driver not associated with the vehicle was drivingthe vehicle when the current retrieved vehicle data was retrieved. 53.The telematics device of claim 52, wherein the vehicle parametercomprises one or more of vehicle operating parameters, a vehicleidentification number (VIN), or combinations thereof.
 54. Thetelemtatics device of claim 52, wherein performing a fraud actioncomprises reporting the results of the comparison to a centralmonitoring station.
 55. The telematics device of claim 52, whereinperforming a fraud action comprises sending an alert from the centralmonitoring station to an interested party.
 56. A computer systemconfigured to perform the steps of a method for detecting a stolenvehicle, the method comprising: receiving, by the computer system, datacorresponding to at least one vehicle parameter from a telematics devicecoupled to a vehicle bus, wherein the telematics device retrieved thedata over a predetermined period; evaluating the data corresponding tothe at least one vehicle parameter retrieved by the telematics deviceover the predetermined period; generating, by the computer system, avehicle identification profile based on the evaluating of the data thatthe telematics device retrieved over the predetermined period; storingthe vehicle identification profile to a memory; comparing currentreceived vehicle data with the stored vehicle identification profile;determining, by the computer system, whether a driver not associatedwith the vehicle drove the vehicle when the current received vehicledata was retrieved by the telematics device if the current receivedvehicle data does not substantially match one, or more, stored vehicleidentification profile, or profiles; and performing a fraud action ifthe current received vehicle data does not substantially match the one,or more, stored vehicle identification profile, or profiles.
 57. Thecomputer system of claim 56, wherein the vehicle parameter comprises oneor more of vehicle operating parameters, a vehicle identification number(VIN), or combinations thereof.
 58. The computer system of claim 56,wherein performing a fraud action comprises sending an alert from thecomputer system to an interested party.